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ABSTRACT 


Accepting  the  premise  that  machines  should  be  designed 
suit  the  languages  that  will  be  implemented  on  them,  and 
vice  versa,  this  project  explores  issues  of  language  des 
uninfluenced  by  implementation  considerations.  Our  cone 
is  only  convenience  for  the  development  and  clear  express 
of  algorithms.  Under  this  we  include  simplicity,  a  mini 
of  terminology,  freedom  from  senseless  restrictions,  lack 
useless  redundancy,  inclusion  of  useful  redundancy, 
affinity  of  language  structures  to  thought  structures, 
attempt  is  made  to  introduce  a  discipline  of  langu 
design,  rather  than  sticking  together  favourite  langu 
features. 
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1 


INTRODUCTION 


This  document  is  the  first  of  the  Ideel  Language 
Project  of  the  Comouter  Systems  Research  Group  of  the 
University  of  Toronto.  It  presents  a  language,  named 
Merlin,  to  serve  as  a  target  of  criticism  and  starting  place 
for  improvements,  and  a  discussion  of  design  decisions. 

Two  design  criteria  commonly  listed  in  the 
introductions  to  new  programming  languages  are: 

(a)  a  language  should  be  convenient  for  the  development 

and  clear  expression  of  algorithms 

(b)  a  language  should  be  conveniently  i mplement able  on 

existing  computers. 

The  first  of  these  contains  many  subsections;  among  them: 
simplicity,  lack  of  useless  redundancy,  inclusion  of  useful 
redundancy,  language  structures  that  match  thought 
structures,  i.e. ,  that  allow  levels  of  abstraction,  etc. 
Criterion  (a)  is  unassailable,  although  we  sometimes 
disagree  about  what  contributes  to  it. 


It  is  becoming  accepted  that  computer  designers  should 
include  among  their  criteria  the  goal  of  making  their 
machines  convenient  for  the  implementation  of  programming 
languages.  Those  who  advocate  language-direc-^ed  machine 
design  cannot  also  advocate  machine-directed  language  design 


without  introducing  a  circularity  (or  at  least  a  mutual 


dependence)  into  the  design  criteria.  In  this  project  I 
reject  criterion  (b)  .  There  is  a  legitimate  class  of 
language  designers  who  must  include  criterion  (b) :  a  time 
or  money  constraint  on  implementation  requires  a  compromise 
between  the  criteria  whenever  they  conflict.  But  if  all 
language  designers  concern  themselves  with  matching  the 
capabilities  of  existing  machines,  progress  in  language  and 
machine  design  will  be  limited  by  that  circularity.  In 
Merlin,  I  intend  no  compromises  for  the  sake  of 
implementation  •  I  am  concerned  only  with  convenience  for  the 


opmeni 

:  and 

clear  expression  of 

algorithms.  It  is  in 

sense 

that  I 

use  the  term 

"ideal". 

Much 

effort 

is  spent  on 

learning 

the  complexities  and 

restrictions  of  programming  languages,  on  concern  for  the 
details  of  particular  implementations,  and  on  learning  a 
barrage  of  largely  unnecessary  terminology.  Merlin  is 
intended  to  be  simple,  free  from  senseless  restrictions# 
uninfluenced  by  implementation  considerations,  and  to 
introduce  a  minimum  of  terminology. 

The  particular  choice  of  symbols  in  Merlin  is  not  a 
major  issue  in  this  paper;  the  choice  of  language  features 
is  the  current  concern.  Any  invertible  substitution  of 
notation  is  acceptable. 
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1 .  2  Ij[!2l£ro§n t at i on 

When  we  submi*  a  program  that  fails  to  terminate 
properly,  we  expect  a  message  informing  us  either  that  we 
have  written  nonsense,  or  that  we  have  failed  to  account  for 
some  implementation  limitation.  In  either  case,  it  is 
called  an  "error  message",  implying  error  or  failure  on  the 
part  of  the  programmer.  In  the  first  case,  this  is 
justified,  but  in  -^he  second,  it  is  not.  When  the 
implementation  fails  to  execu'^e  a  legal  program,  the 
programmer  deserves  an  apology,  not  chastisement,  from  th‘= 
imple raent ers.  I  propose  that  "error  messages"  and  "apology 
messages"  !«=  clearly  distinguished,  and  that  they  be 
expressed  in  differen-^  tones  to  the  programmer.  One  measure 
o-*^  the  degree  to  which  an  implementation  meets  the  needs  of 
its  users  would  be  the  frequency  of  apology  messages. 

Berlin,  like  Fortran  and  A.lgol,  cannot  be  completely 
implemented.  There  are  infinitely  many  Berlin  (Fortran, 
Mgol)  programs,  bu-^  all  machines  are  finite.  Therefore 
some  programs  are  not  representable.  Implementers  may  feel 
iustified  in  their  shortcomings,  but  a  programmer  will  feel 
cheated  when  his  program  is  excluded. 

There  are  infinitely  many  numeric  values  in  Merlin, 
although  any  implemen'^'a tion  will  be  able  ro  represent  only  a 
finite  number  of  them.  Similarly,  no  character  value  is 
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■^xcluded  from  the  language;  any  mark  that  can  be  presented 
to  a  computer*,  and  distinguished  from  other  character 
values*,  gualifies  as  a  character  value.  With  the-  right 
graphic  terminals,  the  implemented  set  of  character  values 
could  be  large, 

'^he  reader  may  notice  cons-^ruc+;s  in  Merlin  whose  full 
generali-^y  is  difficult  or  impossible  o  implement  on 
existing  machines,  and  is  seldom  wanted  and  perhaps  never 
needed.  Bur,  as  with  integers,  any  restrictions  imposed 
because  of  i mplementarion  difficulties  should  not  be  made 
part  of  the  language.  If  an  implementer  decides  not  to 
implement  something  that  is  in  fac*:  seldom  wanted,  the 
frequency  of  apology  messages  associated  with  the  omission 
will  be  low,  and  the  decision  will  have  been  a  wise  one. 

•  3  £‘5sen^a2iion 

Sections  2  to  6  are  an  overview  of  Berlin.  They  are 
presented  in  the  order,  and  in  the  terms,  but  not  in  the 
detail,  that  is  appropriat e  to  a  novice.  Many  constructs 
are  presented  by  examples;  the  general  syntax  is  left  to 
Section  7.  where  detail  is  missing,  the  reader's  experience 
is  drawn  upon,  with  one  exception:  precedence  of  operators 
has  not  been  given. 

The  grammar  of  Section  7  is  ambiguous,  but  all  the 
ambiguities  are  harmless  left  and  right  recursions 
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associated  with  the  non- terminal  value.  (These  ambiguities 
are  trivially  removable,  and  if  they  are  removed  in  the 
obvious  way,  the  grammar  becomes  lALP.  (1).) 

Section  8  begins  a  discussion  of  the  language  design. 
In  some  cases,  it  attempts  tc  justify  design  decisions;  in 
some  cases,  alternatives  are  proposed.  The  reader  is 
invited  *o  add  to  Section  8. 
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2  I^LTTfS 

2*  T  Simple  Values 

simple  values  in  Merlin  are: 

(a)  logical  values: 

true ,  false 

Loaical  values  are  unordered. 

(b)  numeric  values:  e.g., 

0^  1,  -1^  5.2,  6.3E-5,  etc. 

There  are  infinitely  many  numeric  values  in  Merlin. 
Numeric  values  are  ordered. 

(c)  character  values:  e.g., 

Ca>,  ($),  ((),  <)),  (  ),  etc. 

Any  mark  that  can  be  presented  to  a  computer  (enclosed 
in  single  quotation  marks),  and  distinguished  from 
other  character  values,  qualifies  as  a  character  value. 
Character  values  are  ordered.  (The  Merlin  language 
does  net  specify,  nor  is  it  limited  to,  any  particular 
alphabet.  An  implementation  will,  of  course,  be 
limited  to  a  particular  alphabet,  and  will  specify  an 
erderino . ) 

(d)  values  introduced  by  the  programmer:  Simple,  unordered 
values  may  be  introduced  in  a  program  by  listing  them, 
followed  by  the  symbols  :  value.  E.g., 

red,  blue,  green:  value 
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(e)  ordered 

values 

introduced  by  the  prog 

rammer:  Simple, 

orde  red 

values 

may  be 

introduced  in 

a  program  by 

listing 

them , 

in  the 

desired  order. 

followed  by  the 

symbols 

:  value 

order. 

F.g.  , 

small,  medium,  large:  value  order 


If  L0G1  and  LOG2  are  logical  values, 

NUM1  and  NUM2  are  numeric  values, 

NUM'  is  a  numeric  value  other  than  C, 

INT  is  any  integer, 

A.NY1  and  ANY2  are  any  two  values, 

ORDT  and  0P.D2  are  two  values  that  are  ordered  with 

respect  to  each  other, 
then  L0G1  is  a  logical  value, 

L0G1  fr  L0G2  is  a  logical  value, 

L0G1  I  LCG2  is  a  logical  value, 

+  NUM1  is  a  numeric  value, 

-  NU?11  is  a  numeric  value, 

NITMI  NUM2  is  a  numeric  value, 

NUMI  -  NUM2  is  a  numeric  value, 

NUMI  *  NUM2  is  a  numeric  value, 

NUM1  /  KDH’  is  a  numeric  value, 

WUM1  mod  NUM"  is  a  numeric  value, 

-^jT  is  a  numeric  value, 

ANY1  =  ANY2  is  a  logical  value, 

ANY1  -.=  ANY2  is  a 


logical  value. 
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O^DI  <  OPD2  is  ^  logical  value, 

0RD1  <=  0RD2  is  a  logical  value, 

0RD1  >  0ED2  is  a  logical  value, 

0RD1  >=  0ED2  is  a  logical  value. 

These  operators  have  their  usual  meaning  and  precedence. 
Precedence  may  be  altered  by  the  use  of  parentheses. 

The  notation 

bj  NU??»  to  Nnf!2 
stands  for  ■‘■he  values 

NUM1,  NDM1+NDM',  N0Ml+2*NUn',  ...,  NUMI+k^NUW' 
where  k  is  some  integer  such  that,  for  positive  NUU', 

NUMT <=  N0f^2  &  NUM2  <  NIT M 1  (k+ 1 )  *NUM  • 

or,  for  necative  NUfT®, 

NOfn+k*NUN’  >=  NTJM2  Z  NUM2  >  NUMI-?- (k+ 1)  *NIJM ' 

The  notation 

NUN1  to  NUM2 

stands  for 

NUf^l  by  1  ^o  NDM2 

For  example,  1  to  2.5  stands  for  1,  2 

1  to  1  stands  for  1 

to  0  stands  for  no  values 
1  to  -1  is  unacceptable. 

The  notation 


0HP1  to  0Rb2 
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may  be  used  with  any  ordered  values,  with  limitations 
analogous  to  the  above. 

2.2  Structured  Values 

Values  may  be  structured  into  sets,  or  lists. 

(a)  A  set  consis+s  of  zero  or  more  values,  bracketed  by  f 
and  } ,  F . q, , 

n  to  9},  f3,  true,  [  },  etc. 

Any  value  may  be  an  element  of  a  set.  In  a  set,  the 
multiplicity  and  order  of  elements  is  irrelevant. 

{3,  2,  2,  1,  3}  =  {1,  2,  3} 

(b)  A  list  consists  of  zero  or  more  pairs  of  values, 
bracke-^ed  by  list  and  □.  E.q., 

T J 5 ,  2: true,  3:{  }  □,  list  n,  etc. 

The  first  member  of  each  pair  is  called  an  index,  the 

second  an  element  of  the  list.  Any  value  may  be  an 

index  or  element  of  a  list.  In  a  list,  the  order  and 

multiplicity  of  its  constituent  pairs  is  irrelevant, 

but  pairs  with  equal  indices  roust  have  equal  elements. 

The  se-^  of  indices  of  a  list  is  called  the  domain  of 

the  list.  For  lists  all  of  whose  elemen'*'S  are  equal, 

there  is  a  short  notation,  e.g., 

list  {1  to  3}  of  truf 

=  list  1:true,  2: true,  3: true  □ 
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^or  lists  whose  domain  is  { 1  t o  n}  for  some  integer  n, 
there  is  a  short  notation:  the  elements  may  be  listed 
in  order  of  index,  bracketed  by  <  and  y.  g. r 
^6,  red,  lrue)>  =  list  1:6,  2:  red,  3 ‘.true  n 
For  lists  whose  domain  is  [1  to  n}  and  whose  elements 
are  all  characters  other  than  ^  or  there  is  a  still 
shorter  notation:  e.g,, 

CB>,  <C>J> 

I f  L  is  a  list  containing  the  index : element  pair  I:E,  then 
Lfll  =  E 

i.e.,  L[  I  1  denotes  the  element  of  L  corresponding  to  the 
index  I,  If  L[I]  is  itself  a  list,  then  its  Jth  element  is 
Lri][  j],  which  may  be  abbreviated  L[I,J],  and  similarly  for 
higher  dimensions. 

If  SI  and  S2  are  sets, 
then  S'’  U  S2  is  a  set  (union)  , 

SI  N'  S2  is  a  set  (non -sy mme t ric  difference  or  removal 

if  present)  , 

SI  A  S2  is  a  set  (intersection). 

If  LI  and  L2  are  lists, 
then  L1  U  l2  is  a  list  (union) , 

LI  \  L2  is  a  list  (removal) , 

L1  A  L2  is  a  list  (intersection) . 

If  SL  is  a  set  or  list,  and  A  is  any  value,  then 
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A  in  SI 

and 

A  -I  in  SL 

are  logical  values,  depending  on  whether  A  is  an  element  of 
the  set  or  list  SL. 


If  SL1  and  SL2  are  sets  or  lists,  then 
SL1  sub  SL2 

is  a  logical  value:  ^rue  if  every  element  of  SL1  is  an 
element  of  SL2,  false  otherwise. 

If  SI  is  a  finite  set  or  list,  then 
card  SL 

is  an  integer  specifying  the  number  of  distinct  elements  of  SI. 

If  I  is  a  finite  list,  then 
length  I 

is  an  integer  specifying  the  number  of  indices  of  L. 

If  L  is  a  list,  then 
domain  I 

is  a  set  containing  the  indices  of  L, 

L  99:1^  domain  I 

If  I  is  a  list  and  S  is  a  set,  then 
L  form  S 

is  a  set  containing  the  elements  of  L  that  corresponds  to 

indices  that  are  elements  of  S. 

L  form  {El,  F2,  ...,  En} 

=  {L[E11,  L[E2],  ...  ,  L[En3} 
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F «  cf .  , 

truf,  91,  small)>  form  [2,  ti}  =  [true,  small} 
LI  and  L2  are  lists,  then 
L1  form  L2 

is  a  list  whose  domain  is  that  of  L2,  and  whose  elements  are 
the  elements  of  LI  corresponding  *:o  indices  that  are 
elements  of  L2. 

L  form  lis^  I1:E1,  InrEn  n 

=  list  II^LfElly  o,.,  In:L[En]  n 

E .  g .  , 

12,  13,  14,  15^  form  *<1,  3,  2,  2> 

=  <<11,  13,  12,  12> 

1  1211  X  the  same  form  as  X:  if  X  is  a  set,  then  L  form 

X  is  a  set;  it  x  is  a  list,  then  L  form  X  is  a  list  with  the 
same  domain. 

If  SL  is  a  set  or  list,  then 
sets  of  SL 

is  the  set  of  all  sets  S  such  that  S  sub  SL. 

II,  12,  ...,  In  are  any  values,  and  SLI,  SL2,  . . . , SLn  are 
sets  or  lists,  then 

lists  I1:SL1,  I2;SL2,  o..,  In:SLn  n 
is  -^he  se<-  of  all  lists  of  the  form 

list  I1:E1,  T2;E2,  In:^n  n 

where 

El  in  SLI  8  F2  in  SI2  8  ...  8  En  in  SLn 
If  the  elements  in  each  of 

{II,  12,  In],  SL1,  SL2,  SLn 

are  ordered,  then  so  ar<==  the  elements  of 
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ii§i§  I1:SL1,  I2:SL2,  In:SLn  n 

If  S  is  a  sel  and  SL  is  a  set  or  list,  then 
lists  S  of  SL 

is  -he  set  of  all  lists  whose  domain  is  S  and  whose  elements 
are  in  SI. 

If  SL  is  a  set  or  lis-^.,  then 
lis^s  of  SL 

is  the  set  of  all  lists  whose  domain  is  {1  to  n1  for  some 
in'^eger  n,  and  whose  elements  are  in  SL.  If  the  elements  of 
SL  are  ordered,  then  the  elements  of  lists  of  SL  are  ordered 
(when  SL  is  a  subset  of  characters,  the  ordering  of  lis-^s  of 
SL  is  the  lexicographic  ordering  among  character  strings) . 

If  NUfI  is  a  number  and  SL  is  a  set  or  list  of  numbers,  then 
NUM  a  SL 

(approximate  operator)  is  that  number  in  SL  that  is  closest 
to  NUM.  In  case  of  a  tie,  the  greater  is  chosen. 

If  LI  is  a  list  whose  domain  is  {1  to  n}  and  L2  is  a  list 
whose  domain  is  (1  to  m}  for  some  integers  n  and  m,  then 
LI  II  L2 

is  the  list  whose  domain  is  [1  to  n+m}  formed  by 
concatenation  of  LI  and  L2. 

If  L  is  a  list,  and  T  and  E  are  any  values  such  that  I  in 
domain  L,  then 


-  m- 


is  a  list  similar  to  L  except  that  L[  I  ]  =  E.  If  L[I]  is  also 
a  list,  with  index  J,  then 

^  I  b;jr  (Lf  I  ]  replace  J  E) 

may  be  abbreviated 

i-  ii£i§ce  I ,  J  b j  E 

and  similarly  for  higher  dimensions. 
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3  NAMES 


The  notation  for  introducing  names  in  a  Merlin  program 
i  s 

NAME1,  NAME2,  NAMFn:  OBJECT 

where  OBJECT  is  information  about  the  object  being  named. 
The  names  then  stand  for  the  object.  The  nameable  objects 
in  Merlin  are  values,  assicrnments  and  modules.  This  section 
deals  with  the  naming  of  values;  we  postpone  presentation  of 
the  naming  of  assignments  and  modules  to  Sections  4  and  6,3, 

3 . 1  Constants 


A  name  tha-*-  stands  for  a  specific  value  is  called  a 
constant.  The  notation  for  giving  a  name  to  a  specific 
value  (defining  a  constant)  is 
NAME:  VALUE 


E ,  g.  , 

five:  5 

means  that,  wherever  five  appears,  it  stands  for  5, 
Denotation  of  the  value  may  include  constants.  For  example, 
seven:  five  +  2 

means  that,  wherever  seven  appears,  it  stands  for  the  value 


7, 


colours:  {red,  blue,  green} 

aives  the  name  colours  to  the  set  containing  the  values  red, 
blue  and  green  introduced  by  the  programmer. 
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Recursive  constant  definitions  are  allowed,  provided 

the  recursion  is  properly  based  (Lewis  Rosen  73).  E.g., 

info,  link,  nil:  value 
nodes:  lists  inf o: integers, 

linktnodes  U  {nil}  n 

is  an  acceotable  definition,  but 

X :  X 

s:  {s} 
a :  b 
b :  a 

are  improperly  based,  and  therefore  unacceptable. 


Four  constants  are  included 


(a) 

logicals 

the 

name 

of 

the 

(b) 

integers 

the 

name 

of 

the 

(c) 

nationals 

the 

name 

of 

the 

(d) 

characters  - 

the 

name 

of 

the 

3.2  Variables 

The  no-^ation 

N^'ME:  var 

introduces  a  name 
them  elements 
way  is  called 
made  to  stand 
notation 


in  Merlin. 

They  are: 

set 

rue. 

false} 

set 

of 

all 

integers 

set 

of 

all 

rational  numbers 

set 

of 

all 

characters 

various  values,  all  of 
A  name  introduced  this 
explicit  variable  is 
by  the  assignment 


n  SL 

that  can  stand  for 
of  the  set  or  list  SL. 
an  explicit  variable.  An 
for  particular  values 
(Section  4) .  For  example. 


Zar  in  integers 

introduces  a  name  i  that  can  stand  for  any  value  in  the  set 


named  integers,  and 
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node:  var  in  nodes 

introduces  a  name  node  that  can  stand  for  any  value  in  the 
set  named  nodes. 

In  the  notation 
NAME:  VALUE 

if  all  names  used  in  the  denotation  of  VALUE  are  constants, 
then  NAME  is  a  constant.  If  at  least  one  name  used  in  the 
denotation  of  VALUE  is  a  variable  (explicit  cr  implicit) , 
then  NAME  is  an  implicit  variable.  ■'=’or  example, 
j:  2*i  +  1 

introduces  an  implicit  variable  whose  value  depends,  as 
specified,  on  the  value  of  explicit  variable  i. 

3 . 3  In£u t 

The  name  of  an  input  device  may  be  introduced,  along 
with  an  assertion  about  the  values  that  will  be  read  on  the 
device,  by  the  notation: 

NAME:  in£ut  in  SL 

where  SL  is  a  set  or  list.  Establishment  of  the 

correspondence  between  the  name  and  the  device  is  beyond  the 

ability  of  the  language.  Particular  installations  will 

allow  introduction  of  particular  names,  such  as  reader  and 

time,  and  check  the  compatibility  of  the  assertions: 

reader:  input  in  lists  {1  to  80}  of  characters 
time:  input  in  lists  {1  to  8}  of  ‘*0123^56789:.’* 
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with  the  named  devices.  When  used,  the  name  of  an  input 
device  stands  for  the  next  value  to  be  read  on  the  device. 
In  this  context,  an  input  device  name  is  considered  to  be  an 
implicit  variable,  sinae  it  stands  for  various  values,  but 
may  not  be  assigned  a  value.  Unless  the  name  of  an  input 
device  has  appeared  in  the  in^lil  notation,  it  may  not  be 
used  to  stand  for  a  value.  Permission  to  use  a  particular 
device  is  granted  or  refused  when  the  correspondence  between 


the 

name 

and 

oft 

he  la 

nguag 

3.4 

Outp 

The 

name 

with 

an  a 

ssert 

the 

devic 

e,  by 

NAME:  output  in  SL 

where  SL  is  a  set  or  list.  Establishment  of  the 
correspondence  between  the  name  and  the  device  is  beyond  the 
ability  of  the  language.  Particular  installations  will 
allow  introduction  of  particular  names,  such  as  printer,  and 
check  the  compatibility  of  the  assertions: 

printer:  output  in  lists  of  characters 
with  the  named  devices.  Output  is  caused  by  assignment  of  a 
value  to  an  output  device,  via  the  assignment  notation 
(Section  4).  In  this  context,  an  output  device  name  is 
considered  to  be  an  explicit  variable,  since  it  may  be 
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assigned  various  values.  Unless  the  name  of  an  output 
device  has  appeared  in  the  output  notation,  it  may  not  be 
assigned  a  value.  Permission  to  use  a  particular  device  is 
granted  or  refused  when  the  correspondence  between  the  name 
and  the  device  is  made,  and  is  beyond  the  ability  of  the 
language. 

A  device  may  be  both  input  and  output,  if  permission  to 

use  its  name  for  both  purposes  is  granted.  E.g., 

disk:  input  in  lists  {1  to  maxtrack}  of 

lists  {1  to  7280)  of  characters 
disk:  output  in  lists  {1  to  maxtrack)  of 

n  12  72  80)  of  characters 
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^  -ASSIGNMENTS 

assignment  is  a  notation  for  associating  values  with 
variables.  As  stated  in  Sect  ion  3,  an  assignment  may  be 
given  names  via  the  notation 

NAME1,  NAME2,  NAMEn:  ASSIGNMENT 

The  names  then  stands  for  the  assignment.  Execution  of 
assignments  is  discussed  in  Section  5.3. 

Simple  Assignment  § 

A  simple  assignment  associates  a  single  value  with  a 
single  explicit  variable,  A  simple  assignment  has  the  form 
NAME  VALDE 

where  NAME  is  an  explicit  variable  introduced  by  the  notation 
NAM^?  var  in  SL 

and  VALUE  is  an  element  of  the  set  or  list  SL.  After  the 
assignment  is  executed  (Section  5) ^  NAME  stands  for  VALUE 
un*il  another  assignment  to  NAME  is  executed.  For  example, 
given  the  variables  introduced  in  Section  3.2,  the 
assignment 

i  10 

means  that  i  temporarily  stands  for  IC^,  and  j  for  21. 

node  <“  list  info^Sj,  links  nil  n 
means  that  node  temporarily  stands  for  that  list. 

OutDut  is  caused  by  assignment  of  a  value  to  an  output 


d evice  ^  e ,  g, 
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printer  <-  ®PEINT  THIS  message'* 
printer  <-  time 

To  the  right  of  an  assignment  arrow,  the  notation  # 
stands  for  the  old  value  of  the  variable  being  assigned  a 
new  value .  E. g. , 

i  <-  #  +  1 

node  <-  #  replace  info  bj  99 
node  <-  list  info: 10,  link:#  a 
node  <-  #[link] 

4 . 2  structured  As sign me n+ s 

In  this  section,  LOG,  L0G1,  LOG2,  ...  are  logical 
values,  ASMTS,  ASMTS1,  ASMTS2,  ...  are  sequences  of 
assignments  (simple  or  structured),  and  SL,  SL1,  SL2,  ... 
are  sets  or  lists. 

A  structured  assignment  associates  zero  or  more  values 
with  variables.  There  are  seven  structured  assignments  in 
Merlin. 


The  assignment 


group 

ASMTS  n 

is 

equiv 

alent 

to  the 

sequence  of 

assignments 

ASMTS 

only 

purp 

ose  is 

to  allow 

a  name  to  be 

given  to  a 

segue 

assi 

gnmen 

ts. 

The 

assignm 

ent 

if  LOG 

then  ASMTS  n 
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is  equivalent  to  ASMTS  if  LOG  is  true,  and  equivalent  to  no 
assianments  if  LOG  is  false* 

The  assignment 

if  LOG 

then  ASMTS 1 
else  ASMTS2  n 

is  equivalent  to  A.SMTS1  if  LOG  is  true,  and  equivalent  -^o 
ASMTS2  if  LOG  is  false, 

';^he  assignment 
case  of 

L0G1S  ASMTS1  or 
L0G2^  A-SMTS2  or 

9 

9 

O 

LOGni  ?-.St*!TSn  a 

is  equivalent  to  one  of  the  ASMTSi  whose  LOGi  is  true.  At 
least  one  of  the  lOGi  lust  be  true.  If  more  than  one  is 
true,  an  arbitrary  choice  is  made.  In  this  context,  else 
stands  for  a  logical  value  that  is  true  if  and  only  if  all 
other  LOGi  are  falsf. 

The  assignfflent 

case  F  in  SL  of 

SL1“  ASMTSI  or 

SL2t  ASMTS2  or 

« 

o 

o 

SLn:  ASMTSn  ni 

where  the  SLi  are  disjoint,  SL  is  their  union,  and  E  is  an 
element  of  SL, 


is  equivalent  to 


-23- 


case 


of 

E“in  SL1 
E  in  SL2 


ASMTS1  or 
ASMTS2  or 


In  this 
elements 


E  in  SLn:  ASHTSn  □ 
context,  else  stands 
of  SL  except  those  in  the 


for  a 
other 


set  containing  all 
SLi. 


The  assignment 

looo  AS  MTS  n 

is  equivalent  to  an  indefinite  repetition  of  ASMTS.  In  this 
context,  the  notation 
exit 

standing  in  place  of  an  assignment,  specifies  the  end  of  the 
repetition. 


The  assignment 

for  NAME  in  SL 
ASMTS  n 

is  equivalent  to  a  repetition  of  ASMTS,  once  for  each 
element  of  SL,  with  NAME  standing  for  a  different  element 
each  time.  If  SL  is  a  list  whose  indices  are  ordered,  then 
NAME  stands  for  the  elements  in  order  of  index.  Otherwise 
the  order  is  arbitrary.  The  name  stands  for  an  element  only 
within  the  enclosed  assignments.  The  name  may  not  be 
assigned  a  value  by  the  assignment  notation.  In  this 
context,  as  in  the  loop,  an  exit  standing  in  place  of  an 
assignment  specifies  the  end  of  the  repetition. 
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■Recursive  definitions  of  assignment  names  are  allowed, 

provided  the  recursion  is  properly  based.  For  example, 

rec:  ^roup  x  <-  #  *  i 

i  <-  t  +  1 

if  i  <  n 

then  rec  no 

is  an  acceptable  definition,  equivalent  to  the  non-recursive 
definition 

rec:  loop  x  <- 

i  <- 

if  i 

but 

f:  f 

g:  group  g  n 
a :  b 
b:  a 

are  improperly  based,  and  therefore  unacceptable. 


#  *  i 

#  +  1 
>=  n 

then  exi't’  nn 
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5  PEOGFAM  and  exec ot ion 

A  program  is  a  sequence  of  statements,  with 
interspersed  comments,  followed  by  end.  Execu-*-ion  of  a 
program  consists  of  performing  the  actions  specified  in  the 
statements  of  the  program  in  a  particular  order.  This 
section  presents  the  comments  and  statements  of  Merlin,  and 
the  order  in  which  statements  are  executed. 

5 . 1  Comments 

A  comment  in  Merlin  has  the  form 
«  ALMOST  ANYTHING  » 

where  ALMOST  ANYTHING  is  any  sequence  of  characters  not 
including  the  comment  delimiters  «  or  >>.  A.  comment  may 
appear  between  any  two  symbols  in  a  program.  A  comment  has 
no  effect  on  execution. 

5.2  Statements 

In  Section  2.1  we  met  two  statements: 

VI,  V2,  ...,  Vn :  value 

VI,  V2,  ...,  Vn :  value  order 

which  introduce  simple  unordered  or  ordered  values. 


In  Section  3  we  met  the  statements 

NAME1,  NAME2,  ...,  NAMFn:  VALUE 
NAMF1,  NAME2,  ...,  NAMEn :  van  in  SL 
NAME1,  NAME2,  ...,  NAMEn:  iniut  in  SL 
NA-MF1,  NAME2,  ...,  NAMEn:  outgut  in  SL 

which  introduce  constants,  variables  and  I/O  device  names, 
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In  S^cnicn  u  we  met  the  statement 

NAMI1,  NAI^S2,  NAMEn:  ASSIGNMENT 

which  gives  rnmes  to  ar  assignment,  and  the  assignment 
NAME  <-  VALUE 

which  is  itself  a  s-atement  that  assigns  a  value  to  a 
variable.  We  also  met  several  structured  assignments 

1222/  l22) /  which  may  stand  as  statements. 

5 . 3  1x2221122  22122 

Sta-^ements  are  executed  in  the  following  order: 

1  Simple  values  are  introduced, 

2  Names  are  introduced, 

2.1  Constants  are  introduced. 

2.2  Variables  and  I/O  device  names  are  introduced. 

2.3  Names  of  assignments  are  introduced. 

3  Assignments  occur. 

The  order  in  which  simple  values  are  introduced  is 

immaterial . 

In  the  absence  of  recursive  constant  definitions, 

constants  are  introduced  in  an  order  determined  by  the 
constants  used  in  the  definitions.  In  the  examples  of 
Section  3.1,  the  introduction  of  the  names  five  and  seven 
occur  in  that  order,  reaardless  of  physical  order,  since  the 
name  five  is  used  in  the  definition  of  seven.  Mutually 
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recursive  constant  definitions  must  be  considered  to  occur 
simultaneously,  after  any  names  used  in  the  base  for  rhe 
recursion  have  been  introduced. 

Explicit  variables  and  I/O  device  names  are  introduced 
before  implicit  variables.  The  order  of  introduction  of 
explicit  variables  and  I/O  device  names  is  immaterial.  The 
order  of  introduction  of  implicit  variables  is  precisely 
like  that  of  constants. 

The  order  of  assignment  name  introductions  is  precisely 
like  that  of  constants, 

Assignment  statements  are  executed  in  the  order  in 
which  they  are  written. 

5 .  Ixam^les 

The  first  example  is  Dijkstra’s  program  for  printing 
good  sequences  (Dijkstra  71),  a  good  sequence  is  a  sequence 
of  Is,  2s,  and  3s  containing  no  adjacent  identical 
subsequences.  We  want  them  in  lexicographic  order,  up  +o 
and  including  the  first  sequence  of  length  IOC,  assuming 
such  a  sequence  exists. 


W  rHi 
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ssguence;  var  in  lists  of  {1  to  3) 

Isn:  leng+h  sequence 

final_digit:  sequencef len ] 

good:  var  in  lo^icals 

printer:  output  in  lists  of  {1  to  3} 

equence  <-  <<first  good  sequence» 

opp  printer  <-  sequence 
if  len  =  ICO 

then  exit  a 

transform  n  <<into  next  good  sequence>> 

transform:  group  extend_with_ 1 

loop  set_good 
if  good 

then  exit  a 
adjust  nn 

sxtend_with_1 :  sequence  <-  #  | | 

adjust:  group  trim_f inal_3s 

increase_f inal_digi t  n 

t.rim_f inal_3s :  loop  if  final_digit  -i=  3 

then  exit  n 

sequence  <-  #  form  ’t*'  12  n 

increase_final_diqit : 

sequence  <-  #  replace  len  by  final_digit  +  1 

set_good:  group  good  <-  true 

for  m  in  <1  to  len/2J> 

if  the_m_sequences_are_equal 
then  good  <-  false 
exit  nn 

the_m_sequences_are_equal : 

sequence  form  <len  -  2*m  +1  to  len  -  m> 

=  sequence  form  <len  -  m  +  1  to  len)> 


end 
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The  second  example,  also  from  Dijkstra  (Dijkstra  12, 

Section  13,  Example  2),  is  a  graph  printing  program.  Assume 

that  fx  and  fy  are  given, 

abcissa:  {1  to  ICO} 
ordinate:  {1  to  50} 
indept:  {1  to  1000} 

lines:  lists  abcissa  of  {<  >,  <*)} 
blank_line:  list  abcissa  of  <  > 

image:  yar  in  lists  ordinate  of  lines 
printer:  output  in  lines 

image  <-  list  ordinate  of  blank_line 
f2I  i  in  indept 
add_s tar  n 

for  line  in  image 

printer  <-  line  n 

add_star:  image  ■^x[i}  by 


end 
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The  third  example,  given  a  graph 

containing  no  more  than  max  nodes.  The 

by  an  adiacency  matrix  adj.  The  nodes 

and  ad-j[i,j1  =  true  if  there  is  an  edge 

if  otherwise,  Assume  that  adj,  n 

printer:  output  in  lists  of  {1  to  n) 
c:  var  in  lists  of  {1  to  n} 
size:  length  c 

initial_nodes:  c  form  '<1  to  size  - 
final_node:  cfsize] 
clique:  var  in  logicals 

c  <-  <<first  cligue>> 

loop  printer  <-  c 


,  prints  all  cliques 
graph  is  represented 
are  numbered  1  to  n, 
between  nodes  i  and 
and  max  are  given. 


transform  <<to  next  clique  or  null>> 
if  c  =  <  )> 


then  exit  nn 


transform:  group  if  final_node  =  n  |  size  =  max 

then  backup 
else  extend  n 
loop  set__clique 
if  clique 

then  exit  n 
if  finel_node  =  n 
then  backup 
else  increment  nnn 


backup:  group  c  <-  in  it ia l_nodes 

if  c  -1=  ■«<  >■ 

then  increment  nn 

extend:  c  <-  #  ||  <final_node  + 

increment:  c  <-  #  replace  size  b'y  final_node  +  1 

set_clique:  group  clique  <-  true 

for  i  in  i n it ial_ nodes 

if  -•adj[i,  final_node] 
then  clique  <-  false 
exit  nnn 


end 
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6  MSTPACTIONS 

The  Ian au age  presented  so  far  is  sufficient  and 
sui'*-able  for  small  programs.  Large  programs,  however,  are 
difficult  to  write,  read  and  change  if  all  names, 
particularly  all  variables,  are  available  everywhere.  The 
three  abstractions  presented  in  this  section  provide  the 
mechanism  for  limitino  name  availability. 

6 . 1  Functions 


A  function  is  an  abstraction  of  a  value.  A  function 
may  stand  anywhere  that  a  value  may  stand.  The  simplest 
form  of  function  is 

211  Sb 

STATEMENTS  □ 

where  SL  is  a  set  or  list,  one  of  whose  elements  is  the 
value  the  function  stands  for,  and  STATEMENTS  is  a  sequence 
of  statements.  These  statements  may  include  value 
introductions,  name  introductions,  and  assignments.  To  find 
which  value  the  function  stands  for,  execute  the  statements 
in  order  according  to  Section  5.3.  Inside  a  function,  the 
notation 

with  VALUE  return 

standing  in  place  of  an  assignment,  terminates  execution  of 
the  function,  and  specifies  the  value  that  the  function 


stands  for 


-32- 


value  or  constant  introduced  outside  a  function  is 
available  for  use  insid e  the  function  unless  it  conflicts 
with  an  introduction  inside  the  function.  An  external  value 


introduction  is  deemed  +0  conflict  with 


an 


i nter  nal 


introducer  ion  if  any  of  the  values  introduced  with  it 
conf 1 ict . 

A  variable,  I/O  device  name  or  assignment  name 
introduced  outside  a  function  is  not  available  for  use 
inside  •*:he  function.  Names  of  input  devices  may  not  be 
introduced  inside  a  function.  These  restrictions  ensure 
that  a  func+ion  stands  for  the  same  value  any  time  it  is 
executed,  and  that  its  execution  will  not  affect  anything  in 
the  enclosing  program.  The  time  of  its  execution  (if  ever) 
is  therefore  immaterial. 

Nothing  introduced  inside  a  function  is  available  for 
use  outside  the  function. 


test_se+ :  function  on  se^s  of  integers 

s :  2.§.r  in  sets  of  integer 

s  f-  {  } 

for  i  in  {0  to  50} 

s  <-  t  U  {2*=«'i}  n 
Hiii  s  return  n 
p:  var  in  test  set 


A  function  may  have  the  form 

function  PAPAMETEP  on  SL 
STATE!1ENTS  n 
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where  P.^PAMETEE  specifies  that  a  constant  definition  must  be 
added  to  those  already  in  the  function  in  order  to  execute 
it.  A  parameter  may  have  the  form 
NAME:  £ar 

specifying  the  name  to  be  defined,  or 
NAME:  par  in  SL1 


s  peci f 
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a 

function  is  an  abstraction  of  a  list  of  lists.  If  only  the 
first  few,  but  not  all,  of  the  arguments  are  supplied  using 
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the  index  notation,  the  result  is 
parameters.  For  example. 


function  of  fewer 


test_set_2:  function  n;  par  in  {C  to  99} 

par  in  {0  to  n}  on  integers 
with  2**i  return  n 
p2:  var  in  test_SGt_2[ 50 ]  ~ 


6  .  2 

routine  is  an  abstraction  of  an  assignment.  A 

routine  may  stand  anywhere  an  assignment  may  stand,  P. 

routine  standing  in  a  seguence  of  assignments  is  executed, 

in  its  turn,  as  an  assignment  would  be.  The  effect  of 

execu-^ing  a  routine  is  a  possible  chang®  in  the  values  of 

some  variables  (including  possible  input  and  output),  A 

rou+-ine  has  the  form 

routine  PARA^IETERS 
IMPORTS 
ST.z^TEMENTS  □ 

where  its  parts  are  as  explained  below. 


ST.^-TEMENTS  is  a  seguence  of  statements  (value 
introductions,  name  introductions,  and  assignments). 
Execution  of  a  routine  consists  of  execution  of  these 


statements  in  order  according 
routine,  the  notation 


Section  5,3.  Inside  a 


return 


standing  in  olace  of  an  assignment,  terminates  execution  of 
the  routine.  (Outside  all  routines  it  terminates  execution 


of  the  program.) 
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A  value  or  corstant  introduced  outside  a  routine  is 
available  for  use  inside  the  routine  unless  it  conflic-^s 
with  an  introduction  inside  the  routine.  An  external  value 


introduction 

is  deemed 

to  conflict  with 

an 

internal 

introduction 

if  any  of 

the  values  introduced 

with  it 

conflict. 

IMPORTS 

specifies 

the  explicit 

variables  and 

input/out  put 

device  names 

introduced  outside 

a  rout 

ine  that 

are  available  for  use  inside  the  routine.  IMPORTS  has  the 
form 

NAHE1,  NAM  12,  ...,  NAMEn 

listing  those  explicit  variables  and  I/O  device  names  whose 
values  are  known  during,  or  may  be  changed  by,  execution  of 
the  routine. 

An  implicit  variable  or  assignment  name  introduced 
outside  a  routine  is  available  for  use  inside  the  routine 
unless  it  conflicts  with  an  introduction  inside  the  routine, 
or  unless  its  definition  contains  a  variable  or  assignment 
name  not  available  in  -^.he  routine.  A.n  external  routine 
definition  is  deemed  to  contain  a  variable  if  the  variable 
is  imported  by  that  routine. 

Nothing  introduced  inside  a  routine  is  available  for 
use  outside  the  routine. 
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PAPAMETE^S  is  a  sequence  cf  zero  or  more  parameters. 
Each  parameter  is  either  a  required  parameter,  specifyinq 
that  a  constan*  defini+ion  must  be  added  to  those  already  in 
the  routine  in  order  to  execute  it,  or  an  optional 
parameter,  specifying  that  a  constant  definition  already  in 
the  routine  may  be  replaced,  A  constant  definition  that  may 
b<=  replaced  is  called  a  default  definition,  A  parameter  has 
the  form 


NAME : 

par 

s  pec  i 

f vine  the 

name  to  be  def 

ined  or  redefined,  or 

NAME : 

par  in  SL 

speci 

fying  both 

the  name  and 

the  set  or 

list  SL  of 

values  to 

chops 

e  from.  A 

routine  havin 

g  required 

parameters 

may  be 

n  ^  med 

but  not 

executed . 

If  F  is 

a  routine. 

NAME  is  a 

required  or  optional  parameter,  and  VALUE  is  an  acceptable 
value  for  defining  NAME,  then 
Pf-NAME:  VALUF-9 

is  a  routine  liVe  P,  with  optional  parameter  NAME, 
containing  the  default  definition 
NAME:  VALUE 

A  constant  definition  supplied  for  a  parameter  of  a  routine 
is  called  an  argument.  Several  arauments  may  be  supplied 
t  oget  her. 


As  an  example  of  a  routine,  I  present  the  treesort 
algorithm.  Initially,  the  value  of  the  variable  array  is  a 
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lis*-.  whose  domain  is  {1  to  n}  ,  and  whose  elements  have  a 

defined  order  relation.  Finally,  the  value  of  array  is  a 

permutation  of  its  initial  value  such  that  i  <=  j  implies 

arrayC i]  <=  array[j].  For  the  purpose  of  sorting,  array  is 

considered  to  be  a  binary  tree:  rhe  sons  of  array[i']  are 

array[2*i]  and  array[ 2*i  +1], 

sort:  routine  import  array 

array 

for  i  in  -^flcor[n/2]  by  -1  to  1> 
part_order^f  ir St :  i  last:n-J  n 

i  in  by  -1  to  2> 
exchangef-one :  i  other:1-5 
part_orderf-first :  1  last:i-1-§  n 

floor:  function  x:  par  in  nationals  on  integers 

(X  ~  0,5)  a  inf§aens  return  u 

exchange:  routine  one,  other:  par  in  {1  to  n) 

2.mport  array 

array  <-  (#  replace  one  by  other]) 

replace  other  by  #[one]  n 

part_ord€r:  routine  first,  last;  par  in  {1  to  n] 

import  array 

<<partially  orders  the  subtree  root?d>> 
<<at  first,  ending  on  or  before  last,>> 
<<s,t,  each  node  >=  its  sons,  » 

<<Assump+ion ;  the  subtree  is  already  >> 
<<pa rt_ordered ,  with  the  possible  » 

<<exception  of  the  root,  >> 

father,  son:  yar  in  {first  to  last) 
father  <-  first 
loop  if  fath‘=>r  >  last/2 

£222in  n 
son  <-  2*father 
if  son  <  last 

ItsD.  if  array[  son+1  ]>array{  son  ] 
then  son  <-  #  +  1  na 
if  ar ray[  f at her  ]  <=  array[son] 
fffli  22f22n  D 

exchange{-one  :  f  a  ther  other:son-] 
father  <-  son  nn 
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6 . 3  I32^1ii^§ 

A  module  is,  in  a  loose  sense,  an  abstraction  of  the 
naming  mechanism.  It  allows  names  of  related  objects  to  be 
introduced  in  a  related  manner.  A  module  may  be  given  names 
by  the  notation 

NAI'FI,  NAME2,  ...,  NAMEn:  MODULE 

Module  names  are  introduced  during  the  introductions  of 

o-^her  names  (Section  5.3).  A  module  is  executed  when  each 

of  its  names  is  introduced.  A.  module  has  the  form 

PA.PA.METEES 
EXPORTS 
STATEMENTS  n 

where  its  par+s  are  as  explained  below. 

STAxTEMENTS  is  a  sequence  of  statements.  Execution  of  a 
module  consists  of  execution  of  these  statements. 


A  value  or  constant  introduced  outside  a  module  is 
available  for  use  inside  the  module  unless  it  conflicts  with 
an  introduction  inside  the  module.  An  external  value 
introduction  is  deemed  to  conflict  with  an  internal 
introduction  if  any  of  the  values  introduced  with  i-*- 
conf 1 ict . 


A  variable,  I/O  device  name  or  assignment  name 
introduced  outside  a  module  is  not  available  for  use  inside 


the  module 
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A  value  ip.troduced  inside  a  module  is  not  available  for 
use  outside  the  module. 


EXPORTS  specifies 
assignment  names  and  inp 
inside  a  module  that 
module.  EXPORTS  has  the 


•♦■he  names  (constants,  variables, 
ut/output  device  names)  introduced 
are  available  for  use  outside  the 
form 


exj22£i  NA.ME1,  NA.f1E2,  .•*,  NAMEn 
A*  name  NAME1  exported  from  a  module  named  NAME?  may  be  used 
outside  the  module  only  in  the  notation 
NAME2»NA.ME1 


PARAMETERS  is  the  same  for  modules  as  for  routines  (see 
S ection  6.2). 

As  examples  of  modules,  I  present  a  random  variable, 
complex  numbers,  and  a  stack.  Assume  that  pi,  sqrt,  sin, 
cos  and  arctan  are  given  rational  approximations  to  the 
desired  values.  Where  three  dots  appear,  details  have  been 
omitted. 


random:  module  seed:  par  in  ratipnals 

export  variable,  generate 
seed:  ...  <<default>> 
variable:  yar  in  r at ionals 

variable  <-  seed  <<initial  random  value>> 
generate:  ...  <<changes  variable  to  next>> 

«random  value>>  n 


random«generat  e 
X  <-  random»variable 
y  <-  random* variable 
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complex:  module  export  numbers,  cartesian,  polar,  real,  imag, 

mag,  arg,  add,  subtract,  multiply,  divide 

re,  im:  value 

numbers:  lis;^s  {re,  iin}  of  ra*ionals 


cart  esian : 


function 

with 


y*  £§£  in  nationals  on  numbers 
list  re:x,  im:y  a  return  n 


polar: 


inunlinn  theta:  par  in  rationale  on  numbers 
with  lis*  re : r*cos[ the+ a  ],  im : r^sinf theta  ]  p 
r'^turn  a 


real:  function  c:  par  in  numbers  on  nationals 
with  c[ re  ]  return  n 

imag:  function  c:  par  in  numbers  on  rationals 
lilh.  c[im]  return  n 

mag:  function  c:  par  in  numbers  on  nationals 
willl  sqrt[rsg[c]]  return  n 


arg:  function  c:  par  in  numbers  on  rationals 
case  of 

c[re]>C:  with  ar ctanf c[ im ]/c{ re ]  ]  return  or 
c[  re  ]=0  :  with  pi/2  return  or 


c[  re  ]<0 : 

with 

-arcta 

cf  i 

m ]/cr  re 

]] 

add  : 

f  unct 

ion  X 

/  y: 

Ear 

in  nu 

mbers 

on 

numbe 

rs 

w  ith 

list 

re : 

x[  re  ] 

+ 

yr  t 

e] 

im : 

x[  im  ] 

+ 

y[i 

m  ] 

p 

ret 

urn 

p 

subt 

ract : 

f  unct 

ion  X 

r  y 

:  par 

in 

num 

bers 

on 

numb 

ers 

with 

list 

r  e : 

x[  re  ] 

- 

y[  r 

e] 

9 

im : 

x[  im  ] 

— 

yr  im  1 

p 

ret 

urn 

p 

mult 

iply : 

f  unct 

ion  X 

»  y 

:  par 

in 

num 

be 

rs 

on 

numb 

ers 

w  it  h 

list 

re  : 

x[  re  ] 

’^yC 

re] 

- 

x[ 

im] 

*y[  i 

m]. 

im : 

x[re  ] 

*y[ 

im] 

+ 

xr 

im  ] 

*yr  t 

e]  . 

re  tur 

n  p 

di  vi 

de:  function  x. 

y: 

par  in 

nu 

,mbe 

rs 

on 

nu 

mber 

3 

with 

list 

re : 

(x[  re  ] 

*y[ 

re] 

+ 

x[ 

im  ] 

*y[  i 

m  ]) 

im : 

(x[  im  ] 

*y[ 

re  ] 

- 

x[ 

re] 

*yC  i 

m]) 

re  tur 

n  p 

rsg : 

f  unct 

ion  c 

:  par 

in 

numbe 

rs 

on 

ra 

tional 

3 

with 

re  1 

+  c[i 

m  ]’*' 

*2 

return  d 

p 
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stack:  sntriss:  £ar 

export  push,  pop,  top_er:try,  empty 
s:  yar  in  lists  of  entries 
s  > 

top:  length  s 

push:  routine  entry:  per  in  entries 
import  s 

s  <-  #  H  entry  n 
pop:  s  <-  #  form  to  top  -  1^ 
top_ent ry :  s[ t o p ] 
empty;  •‘■op  =  0  n 

complex_s tack  :  stackf-entr  ies:  complex«numbers-} 
in  complex*numbers 
c  <-  complex*cartesian[ 6 , 3 T 
complex_stack»pushf-entry :  c-^ 
c  <~  complex_stack •top_en t ry 
complex_s tack •pop 

In  the  following  variation  of  the  stack  module,  concatenation 
is  assumed  to  be  too  expensive,  and  system  error  actions 
inadequate. 

stack;  module  entries;  par 

sire:  par  in  integers 
export  push,  pop,  top_er.try,  empty 
sire;  10C  <<default>> 
unir.itialired  :  value 

s:  yar  in  lists  {1  to  sire}  of  (entries  U  {uninitia lired} ) 
5  li§i  i2  sire}  of  uninitialized 
top:  yar  in  fO  to  sire} 
top  <-  C 

push:  routine  entry:  par  in  entries 
import  s,  top 
if  full 

then  overflow 
else  top  <-  #  +  1 

s  <-  #  replace  top  by  entry  nn 

Dop:  if  emuty 

then  underflow 
else  top  <-  #  -  1  n 

top_entry:  list  -«empty :  s[  top],  Gmpty;error  nftrue] 

full;  top  =  sire 

empty:  top  =  0 

error:  ... 

over  flow :  ... 

underflow:  ...  n 
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6 . 4  Abst r act i on  Summary 

A  function  is  an  abstraction  of  a  value;  it  may  stand 
wherever  a  value  may  stand;  its  execution  specifies  •♦•he 
value  it  stands  for.  A  routine  is  an  abstraction  of  an 
assignment;  it  may  stand  wherever  an  assignment  may  stand; 
its  execution  specifies  changes  in  the  values  of  variables. 
A  module  is  an  abstraction  of  the  naming  mechanism;  it  may 
be  Given  names;  its  execution  (when  each  of  its  names  is 
in-'-roduced)  introduces  some  related  names. 

All  three  abstractions  may  have  parameters;  a  parameter 
is  a  constant  that  lacks  a  definition  (or,  for  routines  and 
modules,  that  may  be  redefined).  For  functions,  an  argument 
is  provided  by  the  list  indexing  notation;  for  routines  and 
modules,  by  enclosing  the  supplied  constant  definitions 
within  the  brackets  p  and 

Values  and  constants  introduced  outside  an  abstraction 
are  available  for  use  inside,  unless  they  conflict  with  an 
introduction  inside. 

Variables,  and  names  of  assignments  involving  those 
variables,  introduced  outside  an  abstraction  are  not 
available  for  use  inside,  except  as  imported  by  routines. 

Nothing  introduced  inside  an  abstraction  is  available 
for  use  outside,  except  those  names  (constants,  variables. 
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ip.put/out put  device  names,  assignment  names)  exported  by 
modules. 
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7 

The  grammar  is  presented  using  BNF  (Backus-Naur  form) , 
except  that  the  replacement  meta-symbol  is  rather  han 

::=  and  -^he  angle  brackets  enclosing  non- terminals  have  been 
dispensed  with.  The  paragraphing  of  productions  suggests 
paragraphina  rules  for  programs. 

7 . 1  Non- terminalg 


There  are 

19  non-^^er minals  in 

the  grammar.  They  are: 

program 

statement 

statement  s 

assignme  nt 

assignments 

alternative 

alternatives 

value 

values 

someva lues 

map 

maps 

routine 

module 

parameters 

somepa  rameter s 

a  rguments 

somear guments 

ident if iers 

An  identifier  is  a  value  (including  simple  values,  constants 
and  imolicit  variables) ,  assignment  or  module  if  it  has  been 


introduced  as  such 
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7 , 2  Term inals 


There 

are  83  term 

inals  in  the  grammar. 

They  are: 

; 

<- 

n 

• 

# 

1 

& 

{ 

) 

r 

= 

< 

> 

+ 

- 

* 

/ 

lit  it 

a) 

u 

r\ 

{ 

} 

i 

> 

1  1 

9 

tl 

card 

case 

characters 

doma in 

end 

else 

exi* 

2.x£or  t 

false 

lOT 

form 

f  unct ion 

£r  OU£ 

if 

import 

1  Vi 

ingu^ 

inteaers 

length 

list 

lists 

logicals 

loop 

mod 

module 

of 

on 

or 

order 

OU+ 2ut 

gar 

r  at ionals 

replace 

ret  urn 

routine 

sets 

sub 

then 

to 

true 

value 

var 

with 

exolicitvar 

iable  -  an 

identifier  is  an 

expli 

cit  variable 

if 

it  has  been  intr' 

oduced 

as  such 

ir.outdevicename  -  an 

identifier  is  an 

in  out 

device  name 

if  it  has  been  introduced  as  such 
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outpu  tdevicena  me 


i den-*-  if ier 
numbe  r 
character 
quota-*-  ion 


an  identifier  is  an  ou tput  device  name 

if  it  has  been  introduced  as  such 

e, g. ,  sam ,  a  1 ,  a_b 

e.g,,  5,  5«3,  5E-3 

e.a. ,  cx),  (  ) ,  c 

e.g., 


*  3  Value  Ke;^ 


In  •*-he  productions  of  the  following  sec-*:ion,  whenever 
the  non-terminal  value  appears  on  the  right  side,  it  is 
accompanied  in  the  right  margin  by  a  symbol  indicating  what 
values  i-^  may  be.  This  section  is  the  key  to  those  symbols. 

LOG:  logical 
NHM:  number 

NUM':  number  other  than  C 
INT:  integer 
SET:  set 
LIST:  list 

LIST':  list  whose  domain  is  f1  to  n] 

ANY:  anything 

OPD:  anything  ordered 


7 , 4  Productions 


There  are  110  oroductions  in  the  grammar.  They  are: 
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program  -> 

s“^atements  end 

statement  - 

>  identifiers 

value 

1  identifiers 

value  order 

1  identifiers 

va  lue 

ANY 

1  identifiers 

var  in  value 

SET/LIST 

1  identifiers 

1  identifiers 

input  in  value 
output  in  value 

SET/LIST 

SET/LIST 

1  identifiers 

assign  ment 

1  identifiers 

1  assignment 

module 

assignment 

->  explicitvar iable  <-  value 

ANY 

1  out putdevicename  <-  value 

ANY 

3rou£  assignments 
if  value 


LOG 


1 

th^n  assignments  u 
if  valu‘d 

LOG 

then  assignments 
else  assignments  n 

1 

case  of 

alternatives  n 

i 

case  value  in  value  of 

ANY, SET/LIST 

alternatives  n 

1 

loop  assignments  n 

1 

for  identifier  in  value 

SET/LTST 

assignments  n 

1 

exit 

1 

routine 

1 

return 

\ 

with  value  return 

ANY 

1 

module  •  assignment 

alternative 


->  value 
I  else 


assignments 

assignments 


LOG/SET/LIST 


routine  ->  routine  parameters 

im2ort  identifiers 
statements  n 
I  routine  f-  arguments  4 

module  ->  module  parameters 

export  identifiers 
statements  n 
I  module  F-  arguments  ^ 
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value 


expli cit variable 
I  inputdevicename 
!  « 

1  (  value  ) 

f  value  [  values  ] 

I  filliction  parameters  on  value 
statements  n 
1  module  •  value 


LOGICAL  VALUFS 


value  -> 


1 

! 

I 

I 

I 

\ 

I 

I 

I 


true 

false 

value 


value 

Fr 

valu 

e 

value 

1 

valu 

0 

value 

= 

valu 

e 

value 

=  va 

lu 

value 

< 

valu 

c 

val  ue 

< 

=  va 

lu 

value 

> 

valu 

e 

value 

> 

=  va 

lu 

val  ue 

in 

val 

ue 

value 

in  V 

al 

value 

su 

b  va 

lu 

NUMEFIC  VALUES 


value 

! 

1 

1 

I 


! 

I 

I 

I 


number 
+  value 
-  value 
value  t  value 
value  -  value 
value  *  value 
value  /  value 
value  mod  value 
value  **  value 
value  a  value 
card  value 
length  value 


CHAPACTEF  VALUES 


ANY 

LIST 

SET/LIST 

ANY 


LOG 

LOG, LOG 

LOG, LOG 

ANY, ANY 

ANY, ANY 

OFD, ORD 

ORD,ORD 

ORD, ORD 

ORD, ORD 

ANY, SET/LIST 

ANY, SST/LIST 

SET/LIST, SET/LIST 


NUM 

NUM 

NUM, NUM 
NUM, NUM 
NUM, NUM 
NUM, NUM ' 

NUM, NUM* 

NUM,INT 

NUM, SEI/LIST 

SET/LIST 

LIST 


value  character 
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S?T  VALUES 

value  ->  l22ical§ 

I  integers 
I  rationals 
^  £li^I§LCters 
I  {  values  } 

I  f  } 

I  value  U  value 
I  value  \  value 
I  value  A  value 
I  sets  of  value 
I  lists  of  value 
I  lists  value  of  value 
I  ii§l§  maps  □ 

I  f2Sl§.ilL  valu‘d 
I  value  form  value 

map  ->  value  ;  value 

LIST  VALUES 

value  ->  quotation 
I  values  > 

I  i  > 

1  list  maps  n 
I  list  n 

I  list  value  of  value 
I  value  U  value 
I  value  \  value 
I  value  A  value 
I  value  I  I  value 
I  value  re£lace  value  value 
I  value  form  value 


SET, SET 
SET, SET 
SET, SET 
SET/LIST 
SET/LIST 
SET, SET/LIST 

LIST 

LIST, SET 
ANY, SET/LIST 


SET, ANY 
LIST, LIST 
LIST, LIST 
LIST, LIST 
LIST' ,LIST' 
LIST, ANY, ANY 
LIST, LIST 


mao  ->  value  :  value 


ANY, ANY 
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statements  -> 

I  s-*-atements 
s-^  a  temer  t 

identifiers  ->  identifier 

I  iden-*:  if  iers  ,  identifier 

values  ->  sornevalues 

I  values  ,  sornevalues 

sornevalues  ->  value  ANY 


!  value  to  value 
1  value  bY  value  to  value 


0?r,0RD 

NTJM  •  ,  NUM 


assianraents  -> 

I  assignments 
assignment 

alternatives  ->  alternative 

I  alternatives  or 
alternative 

maps  - >  map 

I  maps  ,  map 

parameters  -> 

!  parameters 
some pa  rame ters 

someparame ters  ->  identifiers  :  par 

I  identifiers  :  par  in  value  SRT/LIST 

arauments  ->  someargument s 

I  arauments  someargument s 


somea rguments  ->  identifiers  :  value 


ANY 
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8 

DISC 

USST 

ON 

nnti 

1  r 

e  ce  n  * 

ly 

r 

anyone 

who  kn 

ew  a  programming  langu 

age 

or  t 

wo  co 

uld 

call 

hi 

mself  a 

program 

men.  Fortunat 

ely,  t 

his 

i  s 

chan 

ging 

:  a 

P 

ro 

gra  mme 

r  must 

know  some  programm 

ing 

d  isc 

iplin 

e  ( s 

t  ruct 

ur 

ed 

pr  ogr 

amming. 

or  algorithm 

design 

by 

step 

wise 

ref 

i  neme 

nt 

)  . 

At 

presen 

t,  anyone  who  knows  a 

few 

prog 

r  amrai 

ng  1 

angua 

ge 

s 

can  ca 

11  himself  a  language 

design 

er . 

We  h 

a  ve  n 

0  d  i 

sci  pi 

in 

e 

of  Ian 

guage  d 

esign. 

T  ^ 

— 

is  c 

urren 

tly 

popula 

r  to  de 

sign  languages 

that  cl 

aim 

to  f 

acili 

tat  e 

algo 
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T  suggest  th 

at  language  design 

can 

benefit  from  the  "top-down"  discipline  that  language 
designers  recommend  -*-0  programmers. 

"^his  discipline  begins  with  a  very  small,  very  qeneral, 
highl v-involuted ,  low-redundancy  language  whose  very  few, 
very  general  constructs  embody  on  a  very  abstract  level  the 
goals  (uses)  of  the  languaae.  The  design  then  proceeds  by 
removing  unwanted  involutions,  adding  redundancy  that  will 
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b-?  useful  for  error  'ietection.  The  advantages  of  this 
method  are: 

1  ^e  consciously  decide  which  generalities  or  involutions 
are  good,  and  which  bad. 

2  When  an  entity  is  split  into  a  number  of  less  general 
entities,  the  relation  between  the  new  entities  is 
clearly  defined. 

3  In  a  synthesis  of  language  features,  redundancy  is 
often  not  recognized,  or  if  recognized,  not  useable  for 
error  detection  and  impossible  to  remove.  Accidental 
redundancy  can  provide  opportunities  to  make  errors  of 
form,  rather  than  providing  a  consistency  check  on  the 
programmer's  intent.  Therefore  the  deliberate  addition 
of  redundancy  ■judged  to  be  useful  is  preferable. 

I  do  not  claim  to  have  designed  Merlin  in  a  purely 
"top-down"  manner.  3!vcn  in  the  design  of  simple  programs, 
one  makes  mistakes,  and  has  to  back  up  and  change  earlier 
decisions.  The  vast  majority  of  the  numerous  changes  in  the 
design  of  Merlin  are  not  instructive,  and  I  shall  not 
inflict  a  record  of  the  actual  design  process  upon  the 
reader.  Instead  I  present  the  tree  of  decisions  as  it  now 
stands.  The  following  table  depicts  the  upper  (nearest  the 
root)  levels  of  the  tree. 
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language,  can  have  an  even  greater  effect.  Unfort  unate ly, 
it  is  difficult  to  conduct  a  controlled  experiment  (all 
o-^.her  factors  equal)  to  measure  the  effect,  and  hence  to 
justify  language  design  decisions. 

It  is  the  purpose  of  this  section  to  make  explicit  the 
decisions  that  have  been  made,  tc  offer  justification  where 
possible,  and  to  list  some  viable  alternatives. 


8  .  1  Simple  Values 

Given  that  intea^rs  and  division  are  both  in  the 
languaae,  all  rational  numbers  can  be  represented.  The 
restrictions  on  legal  operands  of  /  and  **  ensure  that  only 
nationals  are  in  the  language.  This  decision  is  not  easily 
defended.  We  could  include  tinfinity,  -infinity, 
indeterminate,  and  complex  nationals  simply  by  removing 
these  restrictions.  No  statement  on  principles  of  language 
design  is  int^^nded  by  the  choice  of  representable  numbers, 
and  arithmetic  operations.  Fortunately,  these  decisions 
have  no  impact  on  any  other  aspect  of  the  language. 

As  it  stands.  Merlin  may  not  be  not  satisfactory  for 
numerical  analysts.  They  have  traditionally  busied 
themselves  analysing  the  errors  in  their  computations 
resulting  from  two  sources:  the  finite  speed  of  our 
machines,  i.e.,  they  cannot  do  an  infinite  number  of 
arithmetic  operations  in  a  finite  time;  and  the  imprecision 


not 


and  peculiarities  of  arithmetic  operations.  It  is 
reasonable  to  suppose  that  the  first  of  these  problems  can 
be  overcome.  It  is  reasonable,  however,  to  suppose  that 
machines  can  be  built  to  do  arithmetic  exactly,  but  at  a 
price:  operations  on  longer  operands  will  cost  more.  The 

second  problem,  therefore,  also  remains  with  us,  but  in 
inverted  form.  Father  than  analysing  the  accuracy  we  are 
given,  we  should  be  ahrle  to  specify  the  accuracy  we  want  to 
pay  for.  T  call  upon  numerical  analysts  to  invent 
specifications  for  arithmetic  accuracy.  According  to  the 
expressed  goal  of  the  Merlin  language,  it  is  most  important 
that  these  specifications  be  independen-^  of  number 
representation.  I  do  not  presume  to  know  what  numerical 
analysts  wart,  but  as  an  illustration  of  an  accuracy 
specification  that  is  independen-*-  of  representation,  I  have 
included  the  a)  (approximate)  operator,  which  allows  ■'•he 
programmer  to  control  approximations  and  rounding. 

8.2  Structured  Values 
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and  lists 
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cf  values  that  it  can  stand  for.  The  choice  of  operations 
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part  of  -^he  store  may  assume  more  than  a  single  name." 

(Wirth  74). 

In  the  description  of  Merlin,  cells  are  not  mentioned. 
A  variable  stands  for  a  value.  The  words  "stand  for"  are 
the  approved  words  for  describing  the  role  of  names  in 
Merlin.  One  may,  of  course,  describe  variables  as  cells 
that  "contain"  or  "possess"  a  value,  but  it  would  be  more 
appropriate  to  say  that  the  value  possesses  the  name. 

One  may  not  say  that  a  variable  stands  for  or  denotes  a 
cell.  In  Merlin,  names  are  not  allowed  to  stand  for  names, 
only  for  values,  assignments,  and  modules.  This  precludes 
pointers  and  named  structures  of  names,  and  it  precludes 
binding  paramet'=rs  by  reference,  name,  or  result.  If  I  bind 
formal  parameter  x' to  actual  parameter  y  by  reference,  i. e. , 
let  name  x  stand  for  name  y,  I  am  saying:  "When  I  look  like 
I'm  assigning  a  value  to  x.  I'm  actually  assigning  a  value 
to  y.  ".  In  Merlin,  if  I  mean  x,  I  must  say  x,  not  y. 

In  Merlin,  a  constant  is  a  permanent  name  for  a  value, 
and  a  variable  is  a  -temporary  name  for  a  value.  5  is  not  a 
constant;  it  is  a  value. 

8 . 4  ^^cur sion 

In  the  following  pair  of  constant  definitions,  is  the 


recursion  properly  based? 
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a:  b  +  1 
b:  2>!'a  -  2 

How  about  the  following?: 
c :  2  -  1  /c 


8 . 5  Ty2§§ 

In  many  languages  ("Fortran,  Algol  50,  Algol  W,  PL/I, 
A.lgol  68,  Pascal)  a  variable  is  associate!  with  a  "tvpe”. 
In  order  to  allow  a  variable  to  stand  for  values  of  more 
than  one  ,  but  maintain  the  rule  tha-^  a  variable  is 

associated  with  one  typ«=,  Algol  68  invented  "union"  types. 
In  Pascal,  Wirth  wanted  to  be  able  to  restrict  variables  to 
less  than  a  type,  but  still  maintain  the  same  rule;  he 
therefore  invented  "subrange"  types.  The  purpose  of  the 
rule  is  to  permit  type- chec king ,  i.e.,  a  variable  may  or.lv 
be  assigned  values  of  -^he  right  type.  A.s  Habermann  has 
pointed  out  (Habermann  ?3) ,  if  this  intent  is  interpreted 
strictly,  then  a  variable  associated  with  one  subrange  of 
integers  may  not  be  assianed  th®  value  of  a  variable 
associated  with  an  overlapping  subrange  of  the  integers. 
Even  worse,  an  integer  no  longer  has  a  unique  type,  since 
more  than  one  subrange  may  include  it.  One  solution:  invent 
a  new  concept  -  range  -  distinct  from  type,  and  associate  a 
variable  with  a  range.  There  is  a  third  entity  in  Pascal 
sets  -  distinct  from  type  and  range.  This  multiplicity  of 
entities  seems  unnecessary.  In  Merlin,  a  variable  is 
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associated  wi-^-h  •‘rhe  set  of  values  it  can  stand  for;  there  is 
no  notion  of  type  or  range  distinct  from  set, 

is  important  in  most  languages  that  the  operands  of 
an  operator  be  of  the  right  type  for  the  operator,  and  that 
the  type  of  result  be  known  for  further  checking.  But  once 
again,  ’’type"  is  not  flexible  enough.  Some  operators  (e.g., 
comparison)  apply  to  more  than  one  type,  some  (e.g., 
division  and  modulo)  to  less  than  one  type.  To  check  the 
legitimacy  of  an  expression,  we  need  to  know  the  set  of 
legal  operands  for  an  operator,  and  the  set  of  possible 
results:  the  separate  concept  "type"  is  inappropriate, 

Morris  has  published  his  opinion  that  types  are  not 
sets  (Morris  73) .  He  feels  that  types  should  do  two  jobs 
for  Computer  Science  that  sets  do  not  do  for  Mathematics: 
authentication,  and  secrecy.  By  the  first  term,  he  means 
that  an  abstraction  (function,  routine,  module),  when  handed 
a  value  as  an  argument  for  a  parameter,  should  be  guaranteed 
thar  the  value  is  of  the  right  type,  i.e.,  the  type  expected 
by  the  abstraction.  By  the  second  term,  he  means  that 
values  invented  within  a  routine  (or  module)  are  th-'^  private 
business  of  the  abstraction;  their  type  should  be  hidden 
from  the  outside  world.  In  Merlin,  an  abstraction  can  be 
guaranteed  that  any  value  handed  it  is  in  the  right  set; 
this  is  a  more  flexible  guarantee  than  authentication  by 
type.  Secrecy  is  provided  for  all  objects  and  names 
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invented  within  an  abstraction  (except  those  explicitly 
exported  from  modules) . 

Instead  of  associa-^ing  a  variable  with  a  set  of  values 
(as  in  Merlin) ,  or  with  a  type  (as  in  most  languages) , 
consider  the  following  alternative:  h  value-name  is 

associated  with  an  initial  value,  and  the  possible  changes 
in  ^alue  (assignments) .  For  example, 

inc:  if  x  <  10 

_ihen  X  <-  #  +  1 
else  rangerror  n 
dec:  if  x  >  1 

then  X  <-  «  -  1 
else  rangerror  nn 

introduces  a  variable  x  whose  initial  value  is  1,  and  whose 
allowable  assignments  are  inc  and  dec, 

y  I  0  n 

introduces  a  constant  (i.e.,  no  allowable  assignments).  The 
above  suggestion  is  a  modification  of  a  suggestion  by  Jim 
Horning  (private  communication)  . 

In  some  languaoes,  such  as  SNOBOL  and  ^--PL,  a  variable 
is  not  associated  wi-^h  a  type  or  set  of  values:  it  may  be 
assigned  any  value  whatever.  These  languages  are  deficient 
in  that  the  programmer  has  no  way  to  state  anythina  about 
the  intended  use  of  a  variable.  On  the  other  hand,  Merlin 
(and  other  languages)  does  not  allow  the  introduction  of  a 
variable  without  some  statement  of  its  intended  use.  I  have 
n^ver  needed  to  introduce  a  variable  without  knowing  a 
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sup^rset  of  its  possible  values,  but  the  ability  to  do  so 
could  be  added  to  Merlin  by  the  notation 

NAMF1,  NAME 2,  NAMEn:  yar 

similar  to  the  specification  of  parameters  without 
associating  a  set  of  possible  values.  This  ability  seems 
useful  for  parameters,  for  defining  an  abstraction  that 
cares  about  the  structure  of  a  parameter  but  not  its 
elements  (e.q.,  sorting  or  reversing  a  list). 

APL  and  SNOBOL  hav‘=‘  the  further  deficiency  (as  do 
Fortran  and  PL/I  default  declarations)  that  the  programmer 
cannot  even  state  what  variables  will  be  used.  In  SNOBOL, 
variables  may  be  created  dynamically,  and  therefore  cannot 
be  listed  in  the  program.  This  is  simply  a  confusion  of 
prcg'ram  and  data;  variables  should  be  apparent  from  the  text 
of  the  program,  while  -heir  actual  values  need  not  be. 

8 . 6  Input  and  Output 

PL/I  record  and  stream  I/O  may  each  be  accommodated  by 
the  appropriate  device  name  introductions  in  a  suitably 
sympathetic  system.  F.g., 

printer:  output  in  lists  {1  to  132}  of  characters 
or 

printer:  output  in  numbers  U  logicals 

U  lists  of  characters 

I/O  is  a  detectable  effect  on  the  environment,  and 
should  be  subject  to  the  protection  boundaries  provided  by 
abstractions.  If  the  name  of  an  I/O  device  is  introduced 
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outside  a  routine,  and  not  imported  by  the  routine,  then  the 
routine  loses  the  right  to  reference  the  device.  If  the 
name  of  an  I/O  device  is  introduced  inside  a  routine  or 
module,  then  it  is  conceptually  unrelated  to  any  I/O  device 
outside,  and  is  therefore  of  no  interest  outside.  An 
implementation,  having  a  limited  supply  of  readers  and 
printers,  may  teuse  the  same  I/O  device  fop  which  a  name  was 
introduced  outside,  but  they  remain  conceptually  distinct. 

Input  is  strange  in  two  ways.  One  is  that  input  is  th® 
only  operation  whose  interpretation  depends  on  “^he  order  of 
evaluation  wi-^hin  a  simple  assignment: 

S  <-  reader  | |  reader 

The  other  is  the  anomalous  rule  that  input  may  not  be 
introduced  inside  a  function. 

8.7  Simple  Assignments 

In  many  languages ,  a  list  (vector,  array,  string, 
record,  structure,  whatever)  element  may  be  assigned  a  value 
by  notations  such  as 
L[  5]  <-  8 

substr  (I, 5 , 1)  <-  *A* 

I.F  8 

This  suaqests  that  the  value  possessed  by  L  is  changed  in 
some  way.  Can  a  value  be  changed?  Can  36  be  changed?  Of 
course  we  meant  that  L  now  stands  for  -a  different  value. 
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The  notation  in  ^  Merlin  more  clearly  reflects  this 

interpretation : 

L  <-  #  replace  5  by  8 
I  <-  #  replace  5  by 
L  <-  #  replace  F  by  8 

The  name  L  is  made  to  stand  for  the  value  to  the  right  of 
the  arrow. 

In  languages  with  the  notations  L[5]<-8  and  L.F<-8, 
these  notations  may  be  used  to  assign  values  to  part  of  L, 
with  other  parts  of  L  remaining  undefined.  The  notation 
substr  (L, 5, 1) <- • A ’  may  or  may  not  have  this  property.  An 
in-^er preta tion  more  compatible  with  this  fact  is  that  L  is  a 
list  (vector,  etc.)  of  variables,  not  of  values.  Each 
variable  may  individually  be  assigned  values. 

Structured  variables  and  structured  values  are  not  both 
necessary.  Consistent  with  the  decision  that  names  should 
not  stand  for  names  (see  discussion  of  names) ,  I  have  chosen 
in  favour  of  structured  values  and  simple  variables.  This 
is  consistent  also  with  the  decision  that  all  variables 
should  be  apparent  from  the  text  of  the  program  (see 
discussion  of  types) ;  dynamic  arrays  of  variables  (as  in 
T^L/I)  wouli  violate  this  rule,  and  static  arrays  of 
variables  (as  in  Pascal)  seem  -^.oo  restrictive. 

It  may  seem  that  the  Merlin  form  is  less  efficient,  in 
that  it  involves  a  temporary  array.  Mental  inefficiency 
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would  be  a  serious  criticism,  bu*  I  feel  the  Merlin  form  is 
clearer.  Implementation  inefficiency  is  both  irrelevant  and 
unfounded.  Just  as  the  assignment 
i  <-  #  +  1 

may  be  done  "in  place"  on  a  machine  that  has  that 
capability,  so  the  above  assignments  need  not  involve 
copying  the  value  of  L, 

8 • 8  Structured  Assignments 

The  general  form  of  case  statement  in  Merlin  is  exactly 
the  selection  (if)  construct  cf  Dijkstra’s  guarded  command 
ser.  The  repetition  (do)  construct  may  be  created  as 
f  ollow's: 

case  of 

L0G1;  STMTS1  or 

lOGn:  STMTSn  or 
'  ±xit  on 

These  constructs  are  duals,  and  the  equality  of  their  status 
is  reflected  in  Dijkstra's  notation  for  them;  the  above 
notation  unfortunately  lacks  that  equality. 

As  in  Compel  (Tesler  Inea  68)  ,  if  variables  are 

allowed  only  a  single  assianment  each,  assignments  can  be 
ordered  by  allowing  an  assignment  to  proceed  as  soon  as  all 
variables  used  in  denoting  the  value  have  been  assigned 
values.  This  is  exactly  the  order  used  to  give  variables 
their  initial  values  in  PL/I.  The  word  "variable"  here  is 
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inappropr iat e ,  In  Kerlin,  this  is  exactly  the  ordering  of 
constant  definitions.  The  main  difference  between  Compel's 
assignments  and  Merlin's  constant  definitions  is  that  Merlin 
allows  recursive  constant  definitions,  whereas  Compel  allows 
iteration  by  assignment  to  list  elements. 

Three  assignment  control  cor.s-^ructs  that  have  not  been 
discussed,  but  merit  discussion,  are: 

indeterminacy  -  A  general  ind e-^ erminacy  construct  can  be 
crea-t-ed  in  an  awkward  way  from  the  case  construct.  A 
clean,  peneral  construct  is  simply  a  pair  of  assignment 
brackets:  assignments  inside  the  brackets  are  executed 
in  indeterminate  order. 


nondeterminism  -  A.  nondeterministic  choice  operation,  whose 
operand  is  a  set  or  list,  and  whose  result  is  an 
element  (if  any)  that  allows  -t-he  program  to  terminate 
successfully,  can  be  added  (Floyd  67) , 

concurrency  -  A.  pair  of  assignment  brackets  can  indicate 
that  the  enclosed  assignments  may  be  executed 
concurrently.  This  leads  to  consideration  of 
seauencing  within  a  basically  concurrent  construct. 


8 . 9 

Zahn  has  proposed  a  selection  construct  (Zahn  74), 
which  has  been  revised  by  Knu-*-h  into  two  forms,  one  a 
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combined  iter at i on- select  ion  construct  (Knuxh  74)  with  a 

notation  similar  to  the  following: 

lO02  Unlil  ITENTIFIERS 
ASSIGNMENTS 
then  EVENTS  □ 

The  first  line  introduces  the  names  of  some  events.  The 
assignments  are  executed  repeatedly  until  a  statement  of  the 
•'"orm 

signal  EVENT_NAME 

is  executed,  where  EVENT_NAME  is  one  of  the  identifiers  in 
the  first  line.  Each  event  has  the  form 
EVENT_NAME:  ASSIGNMENTS 

Upon  termination  of  the  loop  by  a  sianal  statement,  the 
assignments  cf  the  appropriate  event  are  executed.  Eor 
example : 

i  <-  1 

loop  until  found,  exhausted 

if  ir  i  ]  =  X 

signal  found  a 

if  i  = 

fll®n  signal  exhausted  n 
i  =  #  +  1 

then  found;  printer  <-  i 

exhausted;  printer  <-  ‘’^NOT  TRFP.e’^  n 

Zahn's  construct  may  always  be  transformed  into  a  simple 

loop  with  exits  by  replacing  a  signal  statement,  wherever  it 

occurs  in  the  loop,  by  the  appropriate  event,  followed  by  an 

§2^il*  example: 
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i  <-  1 

loo2  if  I[  i  1  =  X 

Pointer  <-  i 
exit  n 

if  i  =  length  L 

then  printer  <-  *NOT  THEE? 
exi^  n 

i  <-  #  +  1  n 

'"hree  arguments  tha-t-  may  be  advanced  in  support  of 
Zahn's  construct  concern  multiple  exits,  deep  exi+s,  and 
naturalness.  The  last  two  of  these  are  the  cor.tenr  of 
Zahn's  paper.  T  shall  discuss  each  in  turn. 

Inside  Zahn's  loop,  one  event  may  be  signaled  from  more 
•^han  one  place.  My  transformation  may  seem  to  require 
duolicating  the  appropriate  event  srarements  at  each  place. 
But  the  problem  of  wanting  to  do  the  same  thing  in  more  than 
one  place  is  not  specific  to  the  interior  of  loops.  The 
general  solution  already  exists  in  some  form  in  almost  all 
languages;  in  Merlin,  any  assignment  or  group  of  assignments 
may  be  named,  and  referred  to  by  name. 

The  ability  to  exit  several  nested  Zahn  constructs  at 
once,  or  in  steps,  without  restina  logical  values  at  each 
level,  provides  a  nice  solution  to  some  programming 
problems.  Once  again,  my  objection  is  that  the  solution  is 
less  general  than  the  problem,  and  that  the  general  solution 
already  exists.  Suppose  that  we  have  just  executed 
statement  S5  in  a  sequence  of  snatements  Si,  ...,  S20,  and 
that  we  now  wish  to  continue  with  statement  S15  (forward 
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branch,  not  selection).  If  we  are  sysnematic,  "structured" 
proarammers,  there  car  be  only  one  reason  for  finding 
ourselves  in  rhis  predicament;  Si  throuah  S14  (1<i<5)  is 
some  identifiable  (and  therefore  nameable)  task  tha+  we  have 
lust  completed.  The  routine  is  *he  construct  provided  for 
refinement  of  a  task,  and  the  return  statement  accomplishes 
•^he  forward  lump,  whether  it  be  from  within  1C  nested  loops, 
or  no  loop  a+  all.  (Are  two  layers  of  escape  (exi*  and 
return)  necessary?  sufficient?  desirable?) 

The  •'-hird  arcument  is  that  the  notation  closely  matches 
our  natural  -^houqh-^  processes  -  a  sta-^ed  goal  of  the  F^erlin 
lanauage.  Is  it  more  natural  -^o  exit  a  loop,  and  -^hen 
perform  an  ac-^-ion  that  depends  on  where  we  came  from  (reason 
for  exitina)  ,  than  it  is  to  perforin  an  action  that  d‘=>pends 
or  where  we  are  (reason  for  being  here) ,  and  then  exit?  I 
do  no-^  think  so. 

The  arguments  for  dist inau ishable  exits,  i.e.,  signal 
Gven*-_name,  are  equally  valid  or  invalid  for  distinguishable 
returns  from  routines;  we  could  invent  an  analogy  to  the 
signal  statement,  so  that  action  may  be  taken,  at  the  close 
of  the  routine,  "^hat  depends  on  the  reason  for  returning. 
(In  fact,  Zahn's  proposal  was  not  tied  c  looping.)  The 
reader  is  cautioned  that  my  words  may  not  do  justice  to 


Zahn's  arguments;  the  original  paper  should  be  consulted. 
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A  loop  must 
is  us=d  for  this 
conditional  or 
should  be  tied  to 
system  lanquage 
needs  an  escape. 
Is  a  group  not 
constructs? 


have  an  escape:  in  Merlin,  the  symt>ol  exit 
purpose.  ('’’he  escape  must  be  from  within  a 
selection  statement.  Perhaps  the  escape 
a  conditional  construct,  as  in  the  SUE 
(Clark  f  Horning  71).)  No  other  construct 
Yet  return  from  routines  is  also  provided, 
equally  deserving?  What  about  selection 


An  assignment  name  introduction  should  probably  be 

considered  unacceptable  if  it  contains  any  escapes  not 

enclosed,  in  the  introduction,  by  the  escaped  construct. 

fred :  group  ... 

if  condition 
then  exit  n 

•  •  • 

loop  . . . 

fred 

...  D 

In  the  above,  the  exit  is  used  only  within  a  loop,  although 
in  is  defined  outside.  The  exit  is  thus  obscure.  Consider 


also  the  following: 


roui^inf  . .  . 

con  fuse :  if  i  =  j 

Ihen  return  a 

•  •  • 

-f  1  <<and  therefore  confuse>> 

•  •  • 

confuse 

•  •  •  13 

•  •  •  n 


^rom  which  routine  is  the  return  intended? 


-71- 


Multi-level  escapes  provi(^e  extra  power  over  sir.qle- 

level  escapes  ir  the  sense  that,  without  them,  extra 

variables  and  tests  may  be  required  (Ledgard  7ti)  ,  However, 

the  clarity  of  a  program  in  which  escapes  are  hidden  is 

dubious.  The  return  from  a  routine  provides  this  power, 

since  it  may  be  hidden  inside  a  loop.  Perhaps  it  should  be 

abandoned.  The  usual  example  favouring  a  muti-level  <=>xit  is 

a  search  fcr  an  element  in  a  two-dimensional  array, 

repor'*:ing  its  posi-'-ion  if  found. 

group  i  <-  1 

loop  j  <-  1 

i92£  11  arrayf i, j]  =  x 

+  hen  found  <-  i.rue 

if  j  =  m 

then  exit  n 
1  <-  #  +  la 
if  i  =  n 

then  exit  □ 
i  +  1  n 

found  <-  false  n 

But  Ledgard  reports  failure  in  an  attempt  to  find  an  example 

+hat  requires  multi-level  exits  for  clarity  (Ledgard  7U). 

Perhaps  the  above  should  be  expressed  as  follows: 

i  <- 
j  <-  'I 

i29E  11  inatrix[i,i]  =  x 

then  found  <-  true 
e  xip  D 

if  j  <  m 

then  j  <-  #  +  1 
else  if  i  <  n 

then  i  <-  #  +  1 
i  <-  1 

else  found  <-  false 
exit 


nnn 
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8.10  Invocaticn  and  Instantiation 

Like  an  assignmen'^,  a  routine  may  be  named,  or  stand  in 
a  sequence  of  assignments  and  be  executed  in  its  turn.  The 
concept  "invocation",  as  a  separa'^e  conceut  from 
"‘=xecuricn" ,  is  unnecessary.  If  R  is  a  routine,  then 
■RC-ARGUMENTS4  is  a  routine  like  R,  except  for  certain 
additions  or  changes  tc  the  constant  definitions.  ^ 
compiler  may  decide  to  -^.ake  advantage  of  the  similarity 
among  such  routines  by  storing  only  one  copy  of  the  common 
portion,  with  appropriate  branching  to  and  from  it  (closed 
orocedures)  .  For  short  rou'^ines,  the  compiler  may  decide 
that  this  "optimization"  is  not  worthwhile  (open 
procedures) .  Put  this  is  an  implementation,  not  a  language 
design,  issue.  Furthermore,  it  is  not  limited  to  routines; 
any  repeated  sequence  of  instructions  may  be  treated 
simila  rly . 

Modules,  which  are  abstractions  of  the  naming 
mechanism,  are  executed  when  names  are  introduced.  The 
concept  "instantiation",  as  a  S'=‘para+e  concept  from 
execution,  is  unnecessary. 

8.11  Parameters 

In  most  languages  (Fortran,  Algol,  FL/I,  Pascal)  a 
parameter  is  a  variable.  In  Merlin,  a  parameter  is  a  name 
that  stands  for  a  value,  a  constant.  If  one  wishes  to 
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M«=-rlin's  ’’prcblent"  is  that 
result.  This  is  •‘•he  fur.ctior  of 
since  name  protection  for  functi 
there  is  no  abstraction  in  Merlin  f 
depends  on  global  variables.  The 
see,  for  examples,  the  pop  routine 


Section  6. 
protection 
added  as 
variables , 
designated 


3.  If  desirable,  it  migh 
from  abstraction.  Or  re 
follows:  If  XI,  X2, 

and  P  is  a  routine  th 
result  variables  VI,  V2, 


a  routine  can't  return  a 
the  function.  However, 
ons  and  routines  differs, 
or  producing  a  value  that 
omission  was  intentional; 

and  random  modul^^  of 
t  be  possible  to  separate 
suit  parameters  could  be 
...,  Xn  are  explicit 
at  introduces  specially 
. . . ,  Vn,  then 


R 


I§sul+  X1<-V1,  X2<-V2, 


•  •  • 


Xn<-Vn  n 
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is  an  assignment  meaning  "Fxecurs  R,  then  perform  the 
indicated  assignments. 

It  is  irritating  +hat  the  -^orm  of  arguments  for 
functions  differs  from  that  of  routines  and  modules. 
Uniform  referents  (Foss  7C)  demands  that  the  1 ist  indexing 
notation  be  used  for  functions.  The  same  could  be  used  for 
routines  and  modules  (as  is  traditional) ,  but  it  is  easier 
to  remember  the  name  of  a  parameter  than  its  position  in  a 
narameter  list.  To  use  a  parameter,  one  must  know  what  it 
is  for,  and  this  information  is  usually  encapsulated  in  a 
well-chosen  name.  Eut  its  position  is  usually  quite 
arbitrary. 

8.12  Protection 


It  is  not  clear  from  the  description  of  Merlin  whether 
names  of  modules  are  automatically  inherited  by 
abstractions,  importable  by  routines,  or  exportable  by 
modules.  Perhaps  protection  rules  should  be  simplified,  as 
in  the  following  char*^: 


1 

outside  to  inside 

1 

1 

inside  tc  outside 

1 

1 

values 

1 

YES  if  no  conflict 

r 

1 

1 

NO 

1 

1 

1 

names  of  values. 

"  T 

1 

NO  except  as 

1 

1 

NO  except  as 

1 

assignments,  I/O 

1 

imported  by 

1 

exported  by 

1 

devices,  modules 

1 

-1 

routines 

1 

1. 

modules 

1 

1 

Constants  need  no 

pro'^ection  from  harm 

by 

inner  refinement 

s. 

but  variables  dc  need  pro'^ection.  A  routine  that  uses  the 
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sin  and  sqrt  functions  should  not  require  a  continuous  chain 
of  permission  from  its  ancestors  for  their  use.  A  function 
or  module  ought  to  be  allowed  to  use  constants  (as  in 
Secrion  5. 4)  ,  but  must  not  be  allowed  to  import  variables. 
Hence  the  present  rules.  The  declarative  redundancy  of 
listing  constants  used  by  abstractions  (exempting  lo3±7als 
etc.?)  may  be  useful,  but  that  is  a  separate  issue  from 
protection . 

A  variable  introduced  outside  a  routine  is  not 
available  for  use  inside  the  routine  unless  it  is  imported. 
"Use"  means  discover  its  value,  or  change  its  value. 
Perhaps  permission  for  these  two  different  uses  should  be 
requested  separately  by  different  notations.  There  is  a 
fine  balance  between  not  specifying  enough  useful 
information  to  aid  in  writing  and  understanding  a  program, 
and  specifying  so  much  that  even  simple  things  become 
complicated.  The  decision  to  provide  a  notation  for 
permission  -^.o  use  a  variable,  but  not  to  specify  the  use 
more  precisely,  is  simply  a  judgement  about  the  best 
balance. 

8.13  8edu n danc^ 

The  statement 


assert  LOG 
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wh^re  LOG  stands  for  a  logical  value  that  must  be  true  when 
the  statement  is  executed,  as  in  Algol  W,  has  no*"  been 
included  in  Merlin.  If  an  implementation  leaves 
verification  of  assertions  until  execution  time,  a  standard 
sys-^em  error  action  will  be  less  informative  than  a 
programmer-specified  action  in  an  if  statement: 
if  -LOG 

then  prin>er  «-  ‘^‘meafINGFUL  MFSSAGF 
return  n 

Fur-^ h ermor e,  a  compiler  may  verify  this  latter  form  prior  to 
execution,  and  inform  -^he  programmer  that  the  statement  is 
equivalent  to  no  statement.  The  advantage  of  assert  is,  of 
course,  as  an  aid  to  *he  compiler,  telling  i-^  which  tests  it 
ouoht  to  attempt  to  verify. 

There  are  several  special  forms  of  assertion  in  Merlin: 

1  introduction  of  a  variable  is  accompanied  by  an 
assertion  about  the  values  that  it  stands  for 

2  a  function  header  includes  an  assertion  about  the 
values  that  are  returned 

3  one  form  of  case  header  includes  an  assertion  about  the 
values  used  as  al  terna-'-i  ve  selectors 

4  specification  of  the  parameters  of  a  routine  or  module 
is  an  assertion  about  which  constan'^s  within  it  will  be 


rede  f ined 
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5  in  specifying  •'•he  paraire+ers  of  a  function,  routine,  or 
module,  a  programmer  may  aive  an  assertion  about  the 
values  -^he  parameters  will  stand  for 

6  the  import  list  of  a  routine  is  an  assertion  about 
which  variables  introduced  outside  are  used  inside 
(alterna'*’ ely ,  the  collection  of  variable  in  trod  uC"  ions 
is  an  assertion  about  which  variables  not  introduced 
outside  are  used  inside) 

7  the  exDcr"'-  list  of  a  module  is  an  asser-^ion  about  which 
names  introduced  inside  are  used  outside 

A.11  of  the  above  are  completely  redundant  in  a  correct 

prog  ram. 


It  would  be  useful  redundancy,  but  visual  pollution,  to 
divide  the  symbol  n  into  t si 1 ,  stsil,  £Uora,  fi,  esac,  £Ool, 
I12ilcnuf,  enituor,  and  eludom.  It  might  have  been 
useful  redundancy,  with  a  different  mathematical  history,  to 
divide  +  and  -  into  separate  symbols  for  unary  and  binary 
operators.  In  general,  a  terminal  symbol  should  be  used  for 
only  one  purpose,  where  "purpose"  is  interpreted  as  narrowly 
as  possible,  except  when  historical  or  aesthetic  reasons 
dictate  otherwise. 

Perhaps  an  overworked  syntactic  class  in  Merlin  is 
identifiers:  they  are  used  for  new  values,  constants 
(including  function  names),  explicit  variables,  implicit 
variables,  assianment  names  (including  routine  names). 


and 
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modulG  r.amGS.  If  each  of  the  above  were  requirof^  to  S'*'art 
wi-^h  a  different  character  (e.q.  ^  for  constants),  the 

cat^^aories  wonld  be  instantly  recognizable,  even  apart  from 
context. 


No  symbol  is  required,  nor  has  been  used,  as  s-^atemen* 
s^oarator  or  terminator.  Perhaps  such  a  symbol  would  be 
useful  redundancy.  ;  is  the  r  adi-!- ional  symbol  for  this, 
A  cleaner  and  safer  choice,  fcr  those  input/output  devices 
tha*  support  it,  is  *  he  line  boundary  or  card  boundary,  with 
a  con"^,  inua ti on  symbol  (e.  q.  ,  t  if  not  used  as  above)  to 
override  or  cancel  untimely  boundaries. 


■^o  reduce  useless  redundancy, 
abbre  via-^  ions  of  Iona,  f re que n  tl y- used 


lin  allows 
cor.  str  ucts . 


som® 

For 


examples: 
abbreviat ion 


1  by  2  *0  8 
1  to  8 

list  (1  to  4)  of  V 

<(x,  y,  2^ 

“■  ABC 


full  form 

1,  3,  5,  ^ 

1,  2,  3,  4,  5 

"'•v,  2:v,  3:v,  4:v  n 
lists  1:s,  2:s,  3:s,  4:s  n 
list  1:x,  2:y,  3:z  n 
list  1:^A^,  2:^B5,  3:<C)  n 


Lti,  j,k1 

L  Ii£ll2§  i/l  hi  ® 
pp-x:  5  ,  y:  10,  z  :  1  5-^ 
if  C  then  A  d 
if  C  then  A1  else  ?2  n 
i  in  S  of  . . .  n 


'^he  for  loop  is  an 
constructs  (name  in-^ 


Lfiir 

^  If.£l§.2S  ^  Iz  (b[  i  ]  t enlace  j  by  e) 
pp-x  :  5-5t-y :  1 :  1  f ^ 

T  abbreviations  of 
I  the  more  general 
J  case  sta'-emen-^ 
the  old  value  of  a  variable 
beir.q  assigned  a  new  value 

abbreviation  of  a  combination  of 

roducticn,  loop,  element  selection. 
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t=st,  exit)  one  of  which  is  net  in  the  language.  This 
omission  corresponds  zo  an  assumption  that  the  ability  to 
select  an  element  from  a  set  (or  lisr)  should  be  used  only 
in  the  controlled  manner  of  a  for  loop. 

The  proarammer  is  provided  with  a  mechanism  that  can  be 
used  to  reduce  useless  redundancy  in  programs:  the  ability 
to  name  values  and  assignments,  and  to  use  those  names  in 
place  of  values  and  assignments.  (Naming  is  often  desirable 
for  clarity,  even  when  it  increases  redundancy.) 

8.14  Concluding  Pemark 

Merlin  is  in*:ended  to  be  convenient  for  the  development 
and  clear  expression  of  algorithms.  Given  a  problem,  there 
are  at  least  two  different  criteria  upon  which  one  chooses 
an  algorithm  to  solve  the  problem:  one  may  choose  an 
algorithm  that  is  most  efficient,  i.e.,  that  requires  least 
computing  resources  (whatever  they  may  be),  or  one  may 
choose  an  algorithm  that  is  most  understandable,  i.e.,  in 


whose  correctness 

one 

has 

most 

con- 

f idence. 

One 

current 

opinion  (Gut tag 

■75) 

is 

that 

one 

should  wr 

X  T.  G 

both  the 

understandable  a 

Igor  i 

t  hm , 

a  nd 

*he 

efficient 

algorithm. 

verify  their  equivalence,  and  thereby  gain  confidence  in  the 
correctness  of  the  efficient  algorithm.  (The  fact  that  •'■he 
general  equivalence  problem  is  unsolvable  is  no  deterrent  to 
solving  a  usefully  large  subproblem.) 
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The  language  most  suited  to  the  expression  of 
understandable  algorithms  may  not  be  the  language  most 
suited  to  the  expression  of  efficient  algorithms.  If  not, 
one  may  wish  to  provide  both  as  parts  of  a  programming 
language  (called  specification  and  implementation  parts). 
Alternately,  we  may  hope  that  someday  compilers  will  be  good 
enough  to  transform  the  understandable  version  into  the 
efficient  version.  In  that  case,  writing  two  algorithms  and 
provina  their  equivalence  may  not  be  the  most  useful  form  of 
redundancy. 
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